home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Gold Collection
/
Software Vault - The Gold Collection (American Databankers) (1993).ISO
/
cdr23
/
combi113.zip
/
COMBI.FAQ
< prev
next >
Wrap
Text File
|
1993-05-03
|
10KB
|
202 lines
This file contains some frequently asked questions about COMBI
and the answers.
Q: My system hangs during (or after) boot or when I start a certain program.
What should I do?
A: You may try the following steps:
1. Disable usage of HMA by COMBI (remove '/H' installation switch).
2. Turn off write caching (remove 'B' from cache options).
3. Disable cache at all (add 'O' to cache options). You may turn
the cache on after successful boot if You see that COMBI does not
attempt to use memory that is not available (run MEM or other
program that can report of memory used by TSRs and device
drivers).
4. Try loading COMBI into low memory (if it is loaded high).
Sometimes there is not enough upper memory for other programs
or device drivers that are loaded after COMBI. COMBI detects
amount of available memory under MS-DOS 5.0+ but not under other
DOS versions. In any case COMBI reports how much memory it uses
so You can decide which region of UMB memory is most appropriate
for it.
5. Try to change the order of COMBI and other device drivers. Only
memory managers and disk managers require to be loaded before
COMBI.
6. Try to find out which program conflicts with COMBI and whether
it is possible to reconfigure it to solve the problem.
7. Send me e-mail with the results. I'll try to suggest a better
solution or fix the bug in COMBI (if it is COMBI's bug).
Q: Is it possible to disable caching of some DOS partitions or network
drives?
A: No. Once installed COMBI caches all physical hard drives regardless
of the types of partitions on them (DOS partitions, disk manager
partitions, compressed partitions, non-DOS partitions) and never
caches network drives or RAM disks. This is not a waste of memory or
processor resources - if a partition (or some region on the hard disk)
is not accessed via BIOS INT 13h then COMBI does not cache it.
Q: My Stacker (or SuperStor) manual recommends not to cache the compressed
drives. How to do that with COMBI?
A: It is recommended not to cache the logical partition created by Stacker
(SuperStor) but not the physical hard disk on which the compressed data
is stored. COMBI's cache speeds up Stacker's (SuperStor's) access to
compressed data rather than DOS's access to already uncompressed by
Stacker (SuperStor) data. So, caching is useful and compatible.
Q: What is the optimal size of the cache buffer?
A: Probably, the larger is the cache buffer the better. It does not take much
longer to find a block in the large cache or to discover that it is not
present. If a certain application program that You run few times completely
fits into the cache with all the data it needs, then it is started much
faster.
Q: How much memory does COMBI use?
A: This depends on installation parameters. You can estimate it the following
way. COMBI's resident code takes about 8 Kbytes, add the size of the
cache block (512 bytes times the block size - 'U:' parameter). The result
(about 12K for default block size) is the minimum contiguous memory block
COMBI may be installed in. The COMBI's data tables require 16 bytes per
cache block, so for 3 Mbytes buffer size (8 sectors per block) it takes
about 12K. The tables might be put into HMA ('/H' switch) if there is
enough HMA available (MS-DOS 5.0 leaves about 16K of HMA) or occupy
the space just after COMBI's code. If COMBI detects that there is not
enough memory for data tables immediately after its code (this is only
possible under MS-DOS 5.0 - other DOS versions do not provide this
information) then it attempts to allocate another memory block (which may
be in UMB or low memory).
For a system with 8 Mbytes of memory if COMBI uses 7 Mbytes it needs
about 40K. So, loading it into a small UMB block may be fatal.
Q: How to flush the cache (force COMBI to write all the blocks that are
changed) from DOS or from a program?
A: The easiest way is not to do that at all - just wait a second then, if
there are dirty blocks in cache, update process is started (You can
see the hard disk LED twinkling) and when it is finished (the LED goes
off) all the blocks are written. There is the only case when that is not
true: if some sectors can't be written from 5th attempt COMBI does not
further try to write them, however, COMBI attempts to update other sectors
from the same block and/or other blocks.
Another way is to run 'COMBI f' to tell COMBI to flush cache. If there
are any errors the program will report that.
When You hit Ctrl-Alt-Del to reboot machine COMBI intercepts the last
key (Del) and forces writing. After the update is done Ctrl-Alt-Del
combination is passed to other programs that might need to perform some
shutdown actions.
If Your program needs to ensure that all blocks are updated to disk
it may issue INT 13h with AH=0, DL=80h (reset hard disks). I suppose that
is a common way supported by many other cache programs.
Q: How to see the statistics of cache hits/misses?
A: Run 'COMBI' without any parameters. If the cache is on You'll see an
output like this:
Statistics:
RAM disk reads: 0/0
RAM disk writes: 0/0
Hard disk reads - requested: 731/4161 , passed to BIOS: 409/2728
Hard disk writes - requested: 65/84 , passed to BIOS: 19/43
In each pair of numbers 'NNNN/SSSS' the NNNN is the number of requests
to read/write and SSSS is the number of sectors requested.
For the example above about 44% ( (731-409)/731 ) of read requests were
satisfied without actual access to hard disk and about 34% of the requested
sectors were found in the cache. An average read request from DOS was
about 5.7 (4161/731) sectors per read. In fact, for such short reads the
seek for cylinder/sector takes most of the time, so the actual saving is
about 44% rather than 34%.
An average write request from DOS was 1.3 sectors while COMBI passed to
BIOS about 2.3 sectors per request. This means that some of requests
to write into adjacent sectors were grouped into a single request. And the
fact that only 51% (43/84) of sectors were actually written indicates that
DOS has been writing into the same sectors before they were actually
updated to disk (this is a common case for FAT and/or directory sectors).
Your statistics may be quite different. For the example above (about
2 Mbytes read from disk) the 44% savings is a good result for the cache
of only 320K buffer size. As regards write statistics when large files
are written to disk the number of actual write requests may be larger
than DOS requested, since COMBI has to split long writes into shorter
(up to block size which is 8 sectors by default). However, this is not a
negative savings because the time while the hard disk seeks for the
requested sector is not idle but belongs to the process which is running.
Q: How can I ensure that some XMS memory is actually loaned to a program?
A: If that program (like Windows or some editors) allows You to run a DOS
program (from DOS shell) You may try 'COMBI' without parameters. Another
part of the output may look like this:
Current status:
buffer size: 320K
current size: 128K
total number of blocks: 78 (8 sectors each)
current number of blocks: 30 (0 - RAM disk, 30 - cache)
Here 320K is the total size of XMS memory allocated to COMBI on
installation and 128K is the amount of memory it currently has at its
disposal. So, the rest 192K are loaned to other programs (for the example
above it was editor).
Warning! When a program that used XMS memory terminates abnormally it
often does not free the allocated XMS. In this case COMBI is unable
to retrieve the whole buffer size back. If You have a utility which
may determine what XMS handles are allocated and free some of them
You may try to free the XMS handle that belonged to terminated program.
However, You should make sure that that handle does not belong to COMBI
or to any other active program.
Q: When the RAM disk was empty MEM (or other program) reported that there
is N Kbytes of XMS available. After I've copied a file of F Kbytes size
to RAM disk the amount of free XMS dropped to about N-2*F instead of
N-F. What happened?
A: This is COMBI's memory reallocation strategy. To prevent some greedy
programs from eating all XMS memory it tries to retain as much XMS
as is already used by files in the RAM disk (if there are some files
already then You might probably need to write there more files) or
half of the rest available - whichever is less. However, the same program
may try to allocate another XMS handle (in this case it gets half of the
rest and so on) or to reallocate the handle it already allocated (in
this case COMBI assumes that the program really knows how mush XMS it
needs and satisfies the request if possible). Or You may try to decrease
COMBI's XMS memory manually by running 'COMBI -N' where the N is the
number of Kbytes You want COMBI to release. Running 'COMBI -N F' does the
same and tells COMBI to stop automatic memory reallocation until
'COMBI F-' is run.
Q: Is write caching more reliable with 'write immediately' option ('I') than
with delayed writing?
I: Probably, yes. If a program that writes to disk hangs (so that it requires
hard reset) then You have a better chance that its data has been written
to disk than with delayed writing. However, that slows down cache
performance and leads to hard disk head twitching when You copy files.
But even this case may save You some time due to usage of hard disk idle
wait periods.